Cuando Anthropic publicó Model Context Protocol en noviembre de 2024, la reacción se dividió en dos. Un grupo vio una idea sensata pero aún inmadura que tardaría años en importar, otro vio el OAuth de los agentes, el protocolo que faltaba para que las integraciones entre modelos y herramientas dejaran de ser cada una específica. Dieciséis meses después, la segunda lectura ha resultado más acertada. MCP está presente en los clientes más usados, hay decenas de servidores listos para producción, y aparecen los patrones propios de un ecosistema maduro. Este artículo recorre el mapa en 2026.
Por qué MCP se consolidó rápido
Tres factores explican la rapidez. Primero, el estándar es simple: un protocolo JSON-RPC sobre stdio o websockets con tres tipos básicos (herramientas, recursos, prompts) y una sola capa de negociación. No intenta resolver autenticación, autorización ni observabilidad más allá de lo mínimo, lo que permitió que la especificación se adoptara sin debate bizantino.
Segundo, los clientes grandes lo soportaron casi a la vez. Claude Desktop lanzó soporte inicial en diciembre de 2024, Cursor lo añadió en febrero de 2025, Zed y Continue siguieron antes del verano, y VS Code con la extensión de Copilot completó el círculo en otoño. Ningún competidor quiso ser el único editor sin MCP con más del 10% del mercado.
Tercero, la comunidad publicó servidores rápidamente. El primer directorio oficial en la organización GitHub de MCP contenía 12 servidores en enero de 2025; a cierre de marzo de 2026 hay más de 400 servidores públicos catalogados, con calidad variable pero cobertura muy amplia. El efecto de red es el clásico: cuantos más servidores, más incentivo para implementar cliente; cuantos más clientes, más incentivo para publicar servidor.
Los servidores que realmente se usan
De los cientos catalogados, un subconjunto acapara la mayoría del tráfico real según datos compartidos por mantenedores y registros públicos. Conviene separarlos por tipo.
Los servidores de productividad más usados son los oficiales de Google Workspace, Microsoft 365, Notion, Linear y Slack. Llevan madurez suficiente para producción y autenticación OAuth bien resuelta. Los tres primeros son implementaciones oficiales del propio proveedor; Linear y Slack tienen implementaciones oficiales plus algunas comunitarias complementarias.
Los servidores de desarrollo con más uso son el de Git (acceso a repositorios locales), GitHub oficial, GitLab, y los conectores a herramientas CI/CD como CircleCI y GitHub Actions. Para bases de datos, los servidores de PostgreSQL, MySQL, MongoDB y Redis están estables y permiten exploración segura (por defecto lectura) con políticas configurables para ampliar permisos.
Los servidores de memoria persistente son una categoría reciente pero ya importante. Permiten a un agente recordar hechos a través de sesiones. Los dos más populares son el de Anthropic (memory-mcp) y Mem0-MCP, con enfoques ligeramente diferentes. El primero es más transaccional, el segundo aplica técnicas de recuperación semántica.
Los servidores corporativos específicos crecen mes a mes. Salesforce, SAP, ServiceNow, Jira, Confluence y HubSpot tienen implementaciones maduras que permiten flujos agénticos en procesos de empresa. La mayoría son mantenidas por la comunidad con soporte creciente de los proveedores originales.
Patrones de despliegue que han emergido
Cuando el ecosistema estaba empezando, cada instalación era ad-hoc. Hoy se reconocen tres patrones claros según contexto.
El patrón local es el del desarrollador individual: servidores MCP corriendo en la misma máquina que el cliente, configurados en un archivo por aplicación. Es cómodo para exploración, privacidad buena y casi nulo coste operativo. Pero no escala: cada desarrollador mantiene su propia configuración.
El patrón proxy corporativo aparece cuando una organización quiere exponer servidores MCP a todo su equipo con auditoría y control. Un proxy central (normalmente MCPHub o soluciones internas) aloja los servidores, los autentica contra el directorio interno (Azure AD, Google Workspace, Okta), y los expone a los clientes mediante autenticación firmada. Permite política centralizada, registros de auditoría y versionado común.
El patrón SaaS gestionado es el más reciente. Proveedores especializados (Zenrows, Composio, Pipedream entre otros) ofrecen servidores MCP alojados con autenticación OAuth hacia terceros gestionada por ellos. El cliente se conecta con un endpoint HTTP autenticado y no tiene que preocuparse de mantenimiento. Es útil para equipos pequeños que quieren acceso a muchos servicios sin operar infraestructura.
La elección entre los tres depende del contexto: equipos técnicos con exigencias de privacidad eligen proxy propio, equipos de producto pequeños eligen SaaS, desarrolladores solos siguen con local.
Problemas que siguen abiertos
Pese a la consolidación, tres problemas estructurales siguen sin respuesta clara y merecen vigilancia.
El primero es autorización granular. MCP delega autorización al servidor, que puede implementarla como quiera, pero no hay estándar para que el cliente exprese “quiero permitir al agente hacer X pero no Y”. En la práctica, muchos servidores ofrecen solo dos niveles (lectura y escritura) y el detalle fino no está disponible. Esto genera riesgo cuando el agente tiene acceso escritura amplio a sistemas sensibles.
El segundo es la calidad inconsistente de servidores comunitarios. Muchos funcionan bien para demos pero fallan en producción: falta de gestión de errores robusta, ausencia de reintentos, timeouts mal calibrados, documentación incompleta. Es el coste de un ecosistema abierto, pero exige disciplina de filtrado antes de adoptar un servidor para uso corporativo.
El tercero es observabilidad. Cuando un agente pasa por cinco servidores MCP para resolver una petición, saber dónde se introdujo un error o por qué tardó 30 segundos requiere trazas distribuidas que hoy ninguna herramienta ofrece de forma integral. La telemetría existe pero es fragmentada. OpenTelemetry empieza a aparecer como capa transversal pero la adopción es desigual.
Comparación con protocolos anteriores
MCP se parece en patrón a protocolos como LSP (Language Server Protocol) para editores, DAP para debugging y, en cierto modo, a los conectores de ODBC para bases de datos en los años noventa. Los tres establecieron una capa común que sustituyó integraciones punto a punto, y los tres pasaron por ciclos parecidos: adopción rápida en clientes principales, proliferación de servidores con calidad heterogénea, consolidación progresiva alrededor de los servidores más cuidados.
La lección histórica es que estos protocolos ganan cuando el incentivo es compartido entre fabricantes de herramientas y proveedores de servicios. MCP tiene ese incentivo: los clientes de agentes quieren no reinventar integraciones, los proveedores de servicios quieren no depender de un único cliente dominante. Cuando ambos intereses coinciden, el protocolo sobrevive.
Mi lectura
A cierre del primer trimestre de 2026, MCP ha cruzado el umbral de protocolo que se usa sin pensar. Para desarrollador, la decisión ya no es si integrar MCP sino qué servidores incluir en un proyecto dado. Para equipo de producto, el coste de incorporar funcionalidad agéntica nueva ha caído bastante porque la mayor parte de la integración ya existe como servidor público revisable.
Lo que queda abierto es el segundo ciclo de madurez: autorización granular estándar, observabilidad integral, y un directorio oficial con curación rigurosa que distinga claramente servidores aptos para producción de los que son ejercicio experimental. Si esos tres frentes se resuelven durante 2026, MCP se consolida como infraestructura silenciosa del ecosistema de agentes, parecido a lo que hizo LSP con los editores. Si no se resuelven, las empresas que construyan sobre MCP van a enfrentar fricciones operativas que hoy se subestiman. El ritmo de avance de los últimos dieciséis meses hace que la primera salida sea la más probable.
